In general, a server may be configured to provide information to one or more clients according to a client/server model of information delivery. According to this model, the server may comprise a storage system that typically contains one or more mass storage devices, such as magnetic hard disks, in which information may be stored and retrieved as desired. The server is usually deployed over a computer network comprising a geographically distributed collection of interconnected communication links, such as Ethernet, optical or wireless links, that allow the clients to remotely access the server's stored information. The clients may include network devices or computers that are directly or indirectly attached to the server via, e.g., point-to-point links, shared local area networks (LAN), wide area networks (WAN) or virtual private networks (VPN) implemented over a public network such as the Internet. Other clients may include software applications executing on computers configured to communicate with the server.
In some client/server arrangements, the server may be configured with a prefetch cache that stores previously-accessed or frequently-accessed client information. As such, the prefetch cache reduces the load on one or more servers (“origin servers”) by performing a prefetch operation to anticipate and retrieve data objects from the origin server before client requests are received based on a preconfigured set of rules or polices, e.g., selected by a system administrator. That is, the prefetch cache performs the prefetch operation to obviate the need for the origin server to process future requests to retrieve these same data objects. Processing of such requests consumes resources of the server and increases the latency associated with servicing the requests, particularly if the data objects must be retrieved from disks of the server. As used herein, a “data object” is broadly defined as any collection of data that is identifiable by a common name, such as a uniform resource locator (URL), and therefore may include conventional files, HyperText Markup Language (HTML) files (“webpages”), streaming media, software applications, JAVA™ applets, etc. Furthermore, a collection of data objects is a “data set”, e.g., a webpage of a website, wherein the term “website” includes both the origin server and the prefetch cache. However, one skilled in the art could contemplate a website including only the origin server with the prefetch cache residing at a different location in the network. Additionally, an “embedded object” is any data object except html, which is stored within a data set or, more precisely, an html file.
Clients typically communicate with the prefetch cache by exchanging discrete packets of data formatted according to predefined file-access protocols, such as the HyperText Transfer Protocol (HTTP), Network File System (NFS) protocol, Common Internet File System (CIFS) protocol, File Transfer Protocol (FTP), etc. A client may issue a file-access request that specifies, among other things, a specific file to access and a particular file operation to perform. The prefetch cache receives the client request, processes the request and, when appropriate, returns a response. For example, the client may issue a file “read” request to the cache and, in response, the cache may return a file-access response containing the client's requested file.
In practice, the prefetch cache can be configured to operate as a “reverse proxy” or “forward proxy” cache. A reverse-proxy cache is a server that stores a selected set of information from one or more origin servers. For example, a multimedia company may copy selected streaming audio or video content from its origin servers to a reverse-proxy cache, which is then used as an “accelerator” for providing access to the selected content. In contrast, a forward-proxy cache is a server that stores network data for a particular set of clients. Accordingly, unlike the reverse-proxy cache, the forward-proxy cache does not necessarily store selected data from specific origin servers and instead may store data from a variety of different origin servers, i.e., based on the network traffic patterns of the cache's associated set of clients.
Communication between the origin server and the prefetch cache involves the exchange of information using communication resources of the server and cache. The communication resources include the allocation of memory or “buffers” and network protocol stacks. A network protocol stack typically comprises layers of software, such as a transport layer, an internetwork layer and a media (driver) layer. The Internet protocol (IP) is an internetwork layer protocol that provides network addressing between the prefetch cache and the origin server, whereas the transport layer provides a port service that identifies each process executing on the cache and server, and creates a connection between those processes that indicate a willingness to communicate.
As used herein, a process is a software program that is defined by a memory address space. An application programming interface (API) is a set of software calls and routines that are made available (exported) by a process and that can be referenced by other processes. Services provided by the process are typically embodied as APIs. For example, services of a database process, such as lookup operations, queries and insertions, are provided via APIs that enable other processes to perform those operations.
Transport layer services may be further embodied as a socket interface comprising a client socket library (contained within each process) and a socket server of the network protocol stack. A process accesses the network protocol stack via the socket interface by creating a process message data structure that is passed to the socket server. The process message is typically embodied as information (data) “payload” appended to a transport header, the type of which depends on the transport layer protocol used by the process. Examples of conventional transport layer protocols include the Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and Raw IP. The TCP transport service provides reliable delivery of the message or packet using a TCP transport header prepended to the packet, while the UDP service provides best efforts delivery using a UDP header. Raw IP denotes a process that does not use the transport provided by the socket interface, but directly interfaces to the IP layer of the network protocol stack.
The prefetch cache and origin server generally utilize their communication resources, such as buffers and network protocol stacks, to enable communication among their processes over the network. For example to establish communication with a receiving process on the destination prefetch cache, a sending process executing on the source origin server constructs a process message using its socket library and passes it to the socket server (or transport layer) of the network protocol stack. The process message includes, inter alia, a destination network address of the prefetch cache, a destination port number of the receiving process and, if appropriate, payload (data). The sending process passes that information as a connection request to its socket library to initialize a socket (i.e., open a virtual connection). The communication resources of the origin server and prefetch cache then establish communication between the processes.
To that end, the socket server also includes a library that is used to create a network layer (e.g., IP) header having, inter alia, source and destination network (IP) addresses. The socket server prepends the IP header to the transport header and passes that “packet” structure to the IP layer, which constructs a media access (MAC) header. The information contained within the packet structure, including any data, is stored in a buffer allocated to the socket. The IP layer performs a lookup operation into a forwarding information base (FIB) to determine an outgoing physical interface for the connection. The FIB includes a forwarding table that contains forwarding information, such as mappings of layer 3 (L3) network addresses to layer 2 (L2) MAC addresses and outgoing interfaces. Upon obtaining the proper outgoing interface, the IP layer prepends the MAC header to the packet structure and passes it to the media layer, which sends the resulting information in the buffer as a packet over the network to the prefetch cache.
As noted, the prefetch cache operating in either reverse-proxy or forward-proxy mode may be used to anticipate client requests using, e.g., a conventional method of object prefetching over a virtual connection or socket between the cache and origin server. In response to a client sending a request to access a data set, e.g., a webpage, the prefetch cache determines whether the data is stored locally on its disks and, if so, sends the data set to the client. Otherwise, the prefetch cache retrieves the data from the origin server over the socket. When retrieving the data, the prefetch cache anticipates future client requests for data objects based on the preconfigured set of rules and, to that end, attempts to retrieve (“cache”) the objects from the server for storage on its disks. In the case of the webpage, the prefetch cache retrieves an html file from the server and examines headers of data objects embedded in the file (embedded objects) to determine whether the objects are cacheable. If so, the prefetch cache instructs the server to send the objects over the socket to the cache. If the embedded objects are uncacheable, the prefetch cache and origin server cooperate to close the socket, and the objects are not retrieved.
Certain data objects may be rendered uncacheable for a variety of reasons. For example, a website administrator may render (i.e., mark) an object as uncacheable in order to obtain an accurate count of the number of times the website is accessed, i.e., the number of “hits on the website.” Here, a count can be taken from the number of times the object is downloaded to a user. Another reason that an administrator may want to mark an object as uncacheable is the object frequently changes, such as in the example of an image file of a local radar display. Note that in both cases, the object may be an embedded object (e.g., an applet) within a file (e.g., an html file). By marking the object as uncacheable, the administrator ensures the user accesses the most up-to-date version of the object.
Website administrators commonly mark embedded objects on a website uncacheable by, for example, setting a cache-control response header of the object to values of no-cache, private, or max-age=0. Uncacheable or no-cache denotes that the object is marked to prevent caching by forcing a request to an origin server before releasing the object each time that the object is requested. Private denotes the object is marked to limit access only to a certain predetermined (end) user or group of end users. For example, after a login page, all the objects on an html mail site may be marked private. Max-age=0 does not automatically render the object uncacheable, but results in the object being uncacheable because the object needs to be revalidated upon every request. The header alerts the cache to only retain the object for 0 seconds and revalidate after the expiration of that time period.
As noted, when an embedded object is uncacheable, the conventional method of object prefetching abandons any prefetch operation and closes the socket between the prefetch cache and origin server. Thus, the conventional method cannot prefetch the embedded object, i.e., the object cannot be retrieved from the origin server and stored on the prefetch cache to obviate future retrieval requests for the object to the server. The present invention is directed to reduce the response time to the client when the embedded objects are uncacheable.